On 7/27/11 3:54 PM, Elwell, John wrote:
> In addition to what Hadriel and Charles say, another consideration is what if you have, in XML, a Session element with fewer than two Participant elements pointing at it? Do we really need to treat this as an error case, or just accept that it is a valid case (be liberal in what you accept)?

I've been harping on this for some time.
Giving up is not a useful strategy for a recorder - better to get as 
much as you can, if if things don't seem quite right.

(There may be exceptions - I gather there are some cases where it better 
to hang up on the caller if you can't record the call. We might need to 
investigate if we should report something from SRS to SRC that will 
allow that to happen.)

	Thanks,
	Paul

> John (as individual)
>
> John Elwell
> Tel: +44 1908 817801 (office and mobile)
> Email: john.elwell@siemens-enterprise.com
> http://www.siemens-enterprise.com/uk/
>
> Siemens Enterprise Communications Limited.
> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
> Registered No: 5903714, England.
>
> Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.
>
>
>> -----Original Message-----
>> From: siprec-bounces@ietf.org
>> [mailto:siprec-bounces@ietf.org] On Behalf Of Hadriel Kaplan
>> Sent: 26 July 2011 17:21
>> To: Charles Eckel (eckelcu)
>> Cc: siprec@ietf.org
>> Subject: Re: [siprec] Review of metadata-03
>>
>>
>> On Jul 26, 2011, at 11:52 AM, Charles Eckel (eckelcu) wrote:
>>
>>> Exactly. A specific URL, perhaps paul@recording.siprec.com and
>>> charles@recording.siprec.com is given out to each person. If I dial
>>> charles@recording.siprec.com, the SRC registered for
>>> charles@recording.siprec.com receives the SIP INVITE and a
>> SIP dialog
>>> (CS) is created between myself and the SRC. The SRC knows
>> it is supposed
>>> to record this on my behalf, so it creates an RS for the
>> CS. I think it
>>> makes more sense for the CS to have a single participant,
>> me. The SRC
>>> could include itself in the CS, but that seems a bit
>> strange and would
>>> be confused with the more general case in which the SRC is
>> collocated
>>> with a UA that is actively participating in the CS and that is also
>>> acting as the SRC.
>>>
>>> I believe you and Partha are both recommending this studio recording
>>> case is handled as a CS with two participant where one just
>> happens to
>>> be an automaton this is silent rather than one that is a
>> real person or
>>> a actively participating automaton.
>>
>> Yup, that's the only logical construct, IMO.  A "user" in the
>> SIP sense does not mean a human being.  It's just a UA (or
>> arguably an AoR instance in that UA).  If there is a UAC and
>> a UAS, then there are two UA's - two "users", even if one of
>> them is "sip:localhost@127.0.0.1".
>>
>> The real question I guess then is what you guys mean when you
>> use the word "participant".  It's not defined anywhere,
>> afaict, other than indirectly through the metadata draft by
>> describing its entry in the xml.  I assume it does not mean
>> human being, since SIP and RTP have no way to detect when a
>> human being is present on the other end. ;)
>>
>>
>>> Also consider the case of a conference bridge acting as an
>> SRC. When the
>>> first person dialing into the conference bridge, is there a
>> CS with two
>>> participants, the first caller and the conference bridge?
>>
>> Yes.
>>
>>> What about
>>> before the first caller joins, is that a CS with two
>> participants, the
>>> conference bridge and the conference bridge. Or is there no
>> CS at that
>>> point?
>>
>> There is a CS, because there is a SIP session between the
>> caller and the bridge.  The caller is the UAC, the bridge is the UAS.
>>
>> -hadriel
>>
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>>
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec
>